This regression was accidentally introduced in rust-lang#31618, and it's just flipping a
boolean!

Closes rust-lang#32254

Just to make sure we don't accidentally break this in the future.

closes rust-lang#31804

Closes rust-lang#31994

They were probably meant as a shorthand for omitted code.

Part of rust-lang#32446 but there should be a separate fix for the issue.

Signed-off-by: NODA, Kai <nodakai@gmail.com>

Index 0 must be a valid char boundary (invariant of str that it contains
valid UTF-8 data).

If we check explicitly for index == 0, that removes the need to read the
byte at index 0, so it avoids a trip to the string's memory, and it
optimizes out the slicing index' bounds check whenever it is zero.

With this change, the following examples all change from having a read of
the byte at 0 and a branch to possibly panicing, to having the bounds
checking optimized away.

```rust
pub fn split(s: &str) -> (&str, &str) {
    s.split_at(0)
}

pub fn both(s: &str) -> &str {
    &s[0..s.len()]
}

pub fn first(s: &str) -> &str {
    &s[..0]
}

pub fn last(s: &str) -> &str {
    &s[0..]
}
```

Rust 1.7.0 and newer appears to require LLVM 3.6.0 or newer when
building against a version that's out of the tree with the --llvm-root
flag.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

Fixes rust-lang#32412

+ Fix a comment and add a test based on it

…t-lang#32475)

Previously, the thread name (&str) was converted to a CString in the
new thread, but outside unwind::try, causing a panic to continue into FFI.

This patch changes that behaviour, so that the panic instead happens
in the parent thread (where panic infrastructure is properly set up),
not the new thread.

This could potentially be a breaking change for architectures who don't
support thread names.

Signed-off-by: David Henningsson <diwic@ubuntu.com>

to careful use of the span from deriving, we
can permit it in stable code if it derives from
deriving (not-even-a-pun intended)

this was required to preserve the span from
the #[structural_match] attribute -- but honestly
I am not 100% sure if it makes sense.

This is a [breaking-change]: according to RFC rust-lang#1445, constants used as
patterns must be of a type that *derives* `Eq`. If you encounter a
problem, you are most likely using a constant in an expression where the
type of the constant is some struct that does not currently implement
`Eq`. Something like the following:

```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;

match foo {
    SOME_CONST => ...
}
```

The easiest and most future compatible fix is to annotate the type in
question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is
not enough, it must be *derived*):

```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;

match foo {
    SOME_CONST => ...
}
```

Another good option is to rewrite the match arm to use an `if`
condition (this is also particularly good for floating point types,
which implement `PartialEq` but not `Eq`):

```rust
match foo {
    c if c == SOME_CONST => ...
}
```

Finally, a third alternative is to tag the type with
`#[structural_match]`; but this is not recommended, as the attribute is
never expected to be stabilized. Please see RFC rust-lang#1445 for more details.

This commit rewrites the `std::sync::Once` primitive with poisoning in mind in
light of rust-lang#31688. Currently a panic in the initialization closure will cause
future initialization closures to run, but the purpose of a Once is usually to
initialize some global state so it's highly likely that the global state is
corrupt if a panic happened. The same strategy of a mutex is taken where a panic
is propagated by default.

A new API, `call_once_force`, was added to subvert panics like is available on
Mutex as well (for when panicking is handled internally).

Adding this support was a significant enough change to the implementation that
it was just completely rewritten from scratch, primarily to avoid using a
`StaticMutex` which needs to have `destroy()` called on it at some point (a pain
to do).

Closes rust-lang#31688

resolve: Minimize hacks in name resolution of primitive types

When resolving the first unqualified segment in a path with `n` segments and `n - 1` associated item segments, e.g. (`a` or `a::assoc` or `a::assoc::assoc` etc) try to resolve `a` without considering primitive types first. If the "normal" lookup fails or results in a module, then try to resolve `a` as a primitive type as a fallback.

This way backward compatibility is respected, but the restriction from E0317 can be lifted, i.e. primitive names mostly can be shadowed like any other names.

Furthermore, if names of primitive types are [put into prelude](https://github.com/petrochenkov/rust/tree/prim2) (now it's possible to do), then most of names will be resolved in conventional way and amount of code relying on this fallback will be greatly reduced. Although, it's not entirely convenient to put them into prelude right now due to temporary conflicts like `use prelude::v1::*; use usize;` in libcore/libstd, I'd better wait for proper glob shadowing before doing it.
I wish the `no_prelude` attribute were unstable as intended :(

cc @jseyfried @arielb1
r? @eddyb

…patterns-2, r=pnkfelix

Restrict constants in patterns

This implements [RFC 1445](https://github.com/rust-lang/rfcs/blob/master/text/1445-restrict-constants-in-patterns.md). The primary change is to limit the types of constants used in patterns to those that *derive* `Eq` (note that implementing `Eq` is not sufficient). This has two main effects:

1. Floating point constants are linted, and will eventually be disallowed. This is because floating point constants do not implement `Eq` but only `PartialEq`. This check replaces the existing special case code that aimed to detect the use of `NaN`.
2. Structs and enums must derive `Eq` to be usable within a match.

This is a [breaking-change]: if you encounter a problem, you are most likely using a constant in an expression where the type of the constant is some struct that does not currently implement
`Eq`. Something like the following:

```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;

match foo {
    SOME_CONST => ...
}
```

The easiest and most future compatible fix is to annotate the type in question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is not enough, it must be *derived*):

```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;

match foo {
    SOME_CONST => ...
}
```

Another good option is to rewrite the match arm to use an `if` condition (this is also particularly good for floating point types, which implement `PartialEq` but not `Eq`):

```rust
match foo {
    c if c == SOME_CONST => ...
}
```

Finally, a third alternative is to tag the type with `#[structural_match]`; but this is not recommended, as the attribute is never expected to be stabilized. Please see RFC rust-lang#1445 for more details.

cc rust-lang#31434

r? @pnkfelix

…uron

std: Fix inheriting stdin on status()

This regression was accidentally introduced in rust-lang#31618, and it's just flipping a
boolean!

Closes rust-lang#32254

std: Rewrite Once with poisoning

This commit rewrites the `std::sync::Once` primitive with poisoning in mind in
light of rust-lang#31688. Currently a panic in the initialization closure will cause
future initialization closures to run, but the purpose of a Once is usually to
initialize some global state so it's highly likely that the global state is
corrupt if a panic happened. The same strategy of a mutex is taken where a panic
is propagated by default.

A new API, `call_once_force`, was added to subvert panics like is available on
Mutex as well (for when panicking is handled internally).

Adding this support was a significant enough change to the implementation that
it was just completely rewritten from scratch, primarily to avoid using a
`StaticMutex` which needs to have `destroy()` called on it at some point (a pain
to do).

Closes rust-lang#31688

…=alexcrichton

Document heap allocation location guarantee

```
14:25 < aidanhs> is there any guarantee that boxes will not move the value on the heap when they are moved?
14:26 <@steveklabnik> aidanhs: ... i'm not sure if it's a guarantee, but it follows, generally
14:26 <@steveklabnik> aidanhs: moves mean memcpy, so you're memcpying the structure of the box itself, which is copying the pointer
14:26 <@steveklabnik> so the pointer won't be updated
14:26 <@steveklabnik> moves cannot do complex things like move the memory around on the heap
14:26 <@kmc> aidanhs: I would say it's guaranteed
14:27 < aidanhs> steveklabnik: yeah, that's what I was thinking, it'd be pretty strange for rust to do something, but I couldn't find any docs one way or the other
14:27 <@steveklabnik> kmc: aidanhs yeah, it's like a borderline thing that we don't explicitly guanratee but i think IS guaranteed by our other guarantees
14:27 <@steveklabnik> mostly that move == memcpy
14:28 < aidanhs> kmc: steveklabnik great thanks! would a PR to the rust reference along these lines be ok?
14:28 < jmesmon> aidanhs: I believe owning_ref has some discussion of that (stable references)
14:29 <@steveklabnik> aidanhs: i would probably take that, yeah
14:29 < aidanhs> jmesmon: thanks, I'll take a look at that
```
https://botbot.me/mozilla/rust/2016-02-22/?msg=60657619&page=18

r? @steveklabnik

std: Add regression test for rust-lang#32074

Just to make sure we don't accidentally break this in the future.

Flatten rustc and rustc_trans module hierarchy slightly.

The following moves were made, in the name of sanity/simplicity:
* `rustc::middle::{cfg, infer, traits, ty}` to `rustc::{cfg, infer, traits, ty}`
* `rustc::middle::subst` to `rustc::ty::subst`
* `rustc_trans::trans::*` to `rustc_trans::*`
* `rustc_trans::save` to `rustc_save_analysis` (cc @nrc)

I've rebased a larger WIP branch on top of this and the only conflicts were in imports, but YMMV.

Some fixes for error recovery in the compiler

doc: remove needless bindings

The extra syntax is more noise than help in simple examples like this

Remove ungrammatical dots from the error index.

They were probably meant as a shorthand for omitted code.

Part of rust-lang#32446 but there should be a separate fix for the issue.

… r=alexcrichton

Add augmented assignment operator impls for time types

r? @alexcrichton

Hardcode accepting 0 as a valid str char boundary

If we check explicitly for index == 0, that removes the need to read the
byte at index 0, so it avoids a trip to the string's memory, and it
optimizes out the slicing index' bounds check whenever it is (a constant) zero.

configure: update required LLVM version

Rust 1.7.0 and newer appears to require LLVM 3.6.0 or newer when
building against a version that's out of the tree with the --llvm-root
flag.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

…lexcrichton

remove broken config

Fixes rust-lang#32412

…ichton

Fix unsound behaviour with null characters in thread names (issue rust-lang#32475)

Previously, the thread name (&str) was converted to a CString in the
new thread, but outside unwind::try, causing a panic to continue into FFI.

This patch changes that behaviour, so that the panic instead happens
in the parent thread (where panic infrastructure is properly set up),
not the new thread.

This could potentially be a breaking change for architectures who don't
support thread names.

…s, r=steveklabnik

Add note on `str` being an unsized type in strings section of book

The book section on Rust strings mentions `&str` and `String` but does not address why `str` is not used directly. This adds a short blurb and a link to the unsized types chapter. The second draft of the book will go more in-depth on this, but this should help a bit for now. Thanks #rust for clarifying this point, and let me know if it needs rewording or different placement 😄.

CC @steveklabnik @Kimundi

Fix the name of the 'check-cargotest' step

Avoid page reload upon hitting "S" when browsing documentation in local mode

The problem seems to have been introduced with commit 2910c00